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PREFACE 


A  local  network  to  give  a  conmander  flexible  access  to  command  and 
control  subsystems  is  needed  in  the  Navy.  The  Command  Center  Network  (CCN)  is 
a  proposed  solution  which  would  front-end  Navy  computers  to  a  local  data  bus 
via  microcomputers.  The  microcomputers,  or  Network  Interface  Units  (NIUs), 
would  provide  software  to  make  the  network  transparent  to  each  of  the  Navy 
subsystems . 

A  glossary  of  CCN  acronyms  and  abbreviations  is  included  at  the  end. 
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1  INTRODUCTION 


In  recent  years  the  Navy  has  initiated  major  efforts  to  provide  user 
access  to  diverse  subsystems  tdiich  contain  information  of  interest  to  the 
afloat  cciwnander.  These  efforts  have  been  frustrated  by  the  fact  that  these 
subsystems  have  been  developed  independently  for  specific  functions  and,  as  a 
consequence,  are  characterized  by  unique  interfaces  and  protocols,  fully 
committed  memory  and  cpu  cycles,  complex  software  that  is  costly  to  modify, 
and  an  interface  which  expects  an  intelligent  user  on  the  other  end.  To 
address  these  issues,  the  Navy  is  developing  a  Command  Center  Network  (CCN) 
for  interconnecting  these  subsystems  in  a  local  environment  such  as  a  ship, 
building,  or  closely  grouped  set  of  buildings.  The  OCN  builds  upon  recent 
developments  in  high  speed  data  bus  technology  and  protocols  developed  for  the 
ARPANET.  Microprocessors  are  used  to  "front  end"  these  unique  subsystems  and 
to  provide  new  protocols  which  facilitate  C2  functions  and  process- to- process 
interactions  without  the  requirement  for  an  intelligent  human  user. 

Figure  1  illustrates  the  configuration  to  be  employed  for  the  initial 
CCN.  This  same  configuration  can  be  kept  in  mind  while  discussing  the  future 
CCN  since  the  only  change  anticipated  is  the  replacement  of  the  PLI  with  some 
other  network  ( ie  Chaosnet).  In  either  case,  the  PDP  11/03s  are  the  NIUs 
which  interface  the  C2  subsystems  to  the  CCN.  The  software  described  in  this 
document  is  software  which  will  run  in  the  PDP  11/03s  and  the  KL-20/40  (since 
the  KL-20/40  has  no  attached  NIU). 

Figure  2  demonstrates  where  in  the  configuration  the  various  programs 
reside . 

A  functional  description  is  presented  for  each  set  of  programs  necessary 
to  interface  C2  systems  (NAVMACS,  DTS,  CCIS,  and  TSA)  to  the  CCN.  (All 
acronyms  are  defined  in  the  Glossary.)  The  C2  subsystems,  as  described  in 
reference  1,  will  be  interfaced  to  the  CCN  by  PDP  11/03  microcomputers  serving 
as  network  front  ends.  The  11 /03s  are  also  referred  to  as  Network  Interface 
Units  or  NIUs.  The  NIUs  consist  of  a  DEC  LSI-11  processor,  64k  bytes  of  RAM, 
four  asynchronous  serial  lines,  a  line  time  clock  and  an  1822  communications 
interface.  The  1822  interface  can  be  used  to  connect  the  LSI-1 1/03  to  an 
ARPANET  IMP  in  a  direct  memory  access  mode  operating  at  50  kbaud. 


1.  CCN  Interface  Requirements,  Westec  Services  Inc,  October  1979. 
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Figure  1.  CCN  configuration. 
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Figure  2.  CCN  program  location. 
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Existing  software  will  be  used  as  much  as  possible,  especially  for  the 
initial  CCN.  THE  NIUs  will  employ  SRI's  MOS  and  the  network  protocols  Telnet 
and  TCP.  SRI’s  software  is  described  in  reference  2.  Telnet  and  TCP  exist  on 
the  KL-20/40  for  TSA's  use,  so  no  NIU  is  necessary  there.  The  remaining 
software  that  needs  to  be  developed  consists  of  those  programs  which  perform 
the  specific  tasks  associated  with  each  C2  subsystem.  These  are  the  programs 
which  are  described  in  this  document.  A  list  of  functions  of  each  set  of 
programs  is  given,  along  with  a  list  of  characteristics  unique  to  each  system 
and  a  discussion  of  what  will  and  won't  be  available  in  the  initial  CCN.  In 
the  following  discussion,  the  descriptions  are  divided  according  to  the 
systems  being  interfaced,  in  the  following  order:  NAVMACS,  DTS,  CCIS,  TSA, 
and  terminal  users.  Both  the  long-term  and  initial  CCN  are  considered,  in  the 
following  order  of  discussion:  long-term  functions,  characteristics  of 
interest  (which  characterize  the  uniqueness  of  each  application),  and  initial 
CCN  capability.  In  the  latter  are  listed  *irst  those  functions  which  will  be 
implemented,  then  all  functions  which  although  not  implemented  for  the  initial 
CCN,  will  be  implemented  later  as  time  permits.  Implementation  will  be 
avoided  for  some  functions  because  of  the  lack  of  mass  storage  devices  on  the 
NIUs  and  for  others  because  of  the  need  to  simplify  the  initial  CCN. 

2  NAVMACS 


2.1  NAVMACS  MESSAGE  RECEIVING  PROGRAMS 

2.1.1  Functional  Requirements 

Deliver  NAVMACS  messages  to  terminal  users  on  the  CCN  as  well  as 
processes  like  TSA  and  IP. 

Allow  a  parameter  indicating  what  kinds  of  messages  the  user  is 
interested  in  receiving.  (The  user,  throughout  this  discussion,  could  be 
a  process,  a  terminal,  or  a  printer.) 

Require  a  user  to  login  or  a  process  to  authenticate  itself. 

Signal  a  user  when  NAVMACS  messages  arrive. 

Allow  a  user  to  file  messages  for  later  retrieval. 

Allow  a  user  to  stop  the  process  at  any  time. 

Inform  the  user  of  net  errors  which  result  in  loss  of  messages. 

Convert  baudot  to  ASCII. 


Employ  a  multiaddressing  scheme  to  deliver  the  same  NAVMACS  message  to 
several  users. 


2.  Terminal  Interface  Unit  Notebook,  by  JE  Mathis  et  al.  Defense  Advanced 
Research  Projects  Agency,  May  1979. 
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Send  each  NAVMACS  message  to  the  NAVMACS  TT-624  line  printer.  (The  line 
printer  is  being  shared  with  other  processes  on  the  CCN . ) 


Allow  the  NSM  to  have  NAVMACS  messages  sent  to  third  parties.  (The  NSM 
can  arbitrarily  decide  that  a  process  or  terminal  on  the  CCN  should 
receive  certain  NAVMACS  messages.) 

Filter  messages  based  on  subject  or  headers. 

Print  only  the  headers  of  messages  for  the  user . 

Inform  the  user  when  the  NAVMACS  processor  is  being  held  off.  (The 
processor  is  held  off  whenever  buffer  space  is  a  problem  or  hardware  is 
malfunctioning. ) 

Allow  a  terminal  user  to  direct  NAVMACS  messages  to  a  third  party. 
Convert  RAINFORM  formatted  messages  to  CCN  format. 

2.1.2  Characteristics  of  Interest 


The  NAVMACS  processor  and  the  attached  NIU  are  shown  in  Figure  3 . 


Figure  3.  NAVMACS  processor  and  NIU. 

NAVMACS  messages  consist  of  baudot  characters  and  are  on  the  average  2100 
characters  long.  The  messages  are  delimited  by  SOM  (start  of  message)  and  EOM 
(end  of  message).  Since  the  NAVMACS  processor  is  normally  sending  the 
messages  to  a  printer  ( ie  the  line  going  to  the  NIU  is  normally  attached  to  a 
TT-624  line  printer),  the  only  way  of  controlling  flow  is  to  set  the  printer's 
ready  line  to  a  low  voltage,  causing  the  NAVMACS  processor  to  stop  sending  the 
current  message.  When  the  ready  line  is  set  to  a  high  voltage  again,  the 
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processor  will  send  the  message  again  in  its  entirety.  Messages  arrive  at  the 
NAVMACS  processor  over  a  communications  link  operating  at  75  baud.  The 
NAVMACS  processor  sends  the  characters  serially  to  the  printer  at  2400  baud. 
The  NAVMACS  processor  has  32k  bytes  of  storage  space  available  for  incoming 
messages,  and  if  this  space  becomes  full  it  is  programmed  to  drop  any  new 
messages  since  there  is  no  mass  storage  device  available. 

2.1.3  Initial  CCN  Capability 

2. 1.3.1  Functions  which  will  be  implemented 
Deliver  NAVMACS  messages. 

Allow  a  parameter  indicating  the  type  of  messages  the  user  is  interested 
in  but  limited  to:  all  messages,  or  only  RAINFORM  formatted  messages. 

Signal  user  when  NAVMACS  messages  arrive. 

Allow  the  user  to  stop  the  process  at  any  time. 

Convert  baudot/AS^JlI . 

Employ  a  multiaddressing  scheme  to  deliver  the  same  NAVMACS  message  to 
several  users .  ( But  the  scheme  used  will  be  to  send  the  message  once  for 

each  interested  user  since  the  TCP  currently  does  not  support  multi¬ 
addressing;  alternatively,  TCP  could  be  modified  to  support  multi¬ 
addressing  . ) 

2. 1.3.2  Functions  which  will  not  be  implemented 

Require  a  user  to  login  or  a  process  to  authenticate  itself. 

Allow  a  user  to  file  a  message  for  later  retrieval. 

Inform  the  user  of  net  errors  which  result  in  loss  of  messages. 

Allow  the  NSM  to  have  messages  sent  to  third  parties. 

Filter  messages  based  on  subject  or  headers. 

Print  only  header  of  message  for  user. 

Inform  the  user  when  the  NAVMACS  processor  is  held  off. 

Allow  a  terminal  user  to  have  NAVMACS  messages  sent  to  third  parties. 
Convert  RAINFORM  formatted  messages  to  CCN  format. 


2.2  NAVMACS  PRINTER  PROGRAMS 

2.2.1  Functional  Requirements 

Print  NAVMACS  messages  on  the  TT-624. 

Direct  user  output  on  the  CCN  to  the  TT-624. 

Store  user  text  for  printing  later  if  the  printer  is  busy. 

Keep  user  text  separate  from  other  users . 

Convert  ASCII  characters  to  baudot  for  the  printer. 

Prevent  users  from  tying  up  the  printer. 

Bnploy  a  priority  scheme  in  granting  access  to  the  printer. 

Inform  the  users  of  success/failure  of  printed  text. 

Require  users  to  login . 

Advise  users  when  the  printer  is  not  available. 

Inform  users  when  the  printer  buffer  space  is  exhausted. 

2.2.2  Characteristics  of  Interest 

Figure  3  applies  here  as  well.  Characters  must  go  to  the  printer  in 
baudot  format  on  a  serial  asynchronous  line.  The  attached  NIU  is  an  LSI-11/03 
with  no  mass  storage  device,  so  buffering  is  limited.  (The  actual  limit  can 
be  determined  only  at  software  development  time . )  The  printer  does  accept  a 
"new  page"  or  "formfeed"  character.  The  line  to  the  TT-624  has  a  ready 
indicator  to  control  the  flow  to  the  printer.  ' 

2.2.3  Initial  CCN  Capability 

2.2.3. 1  Functions  which  will  be  implemented 
Print  NAVMACS  messages  on  the  TT-624. 

Direct  user  output  on  the  CCN  to  the  TT-624. 

Separate  user's  text  from  other  users. 

Convert  ASCII  characters  to  baudot  for  the  printer. 

Prevent  users  from  tying  up  the  printer. 

2. 2. 3. 2  Functions  which  will  not  be  implemented 
Store  user  text  for  later  printing. 
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ESnploy  a  priority  scheme  for  granting  access  to  the  printer. 
Inform  users  of  success/failure  of  their  printed  text. 
Require  users  to  login. 

Advise  a  user  when  the  printer  is  not  available. 

Inform  users  when  the  printer  buffer  space  is  exhausted. 

3  DTS  PROGRAMS 


3.1  FUNCTIONAL  REQUIREMENTS 

Deliver  track  data  from  the  DTS  computer  to  interested  users. 

Deliver  track  data  from  users  to  the  DTS  computer. 

Require  users  to  login  or  processes  to  identify  themselves. 

Prevent  transmission  over  CCN  of  track  reports  containing  no  change  in 
data  field. 

Deliver  tracks  based  on  content  (air  tracks  to  some  users,  surface  tracks 
to  others,  etc). 

Signal  the  user  when  tracks  arrive  from  the  DTS  computer. 

Qnploy  a  multiaddressing  scheme  for  delivering  the  same  tracks  to  several 
users. 

Inform  users  of  success/failure  of  tracks  sent  to  the  DTS  computer. 
Convert  track  data  from  binary  to  ASCII. 

Store  track  data  for  later  retrieval . 

Allow  NSM  to  have  tracks  sent  to  a  third  party  and  filter  on  subject  or 
content;  ie  the  NSM  can  change  the  addressee  list  (for  the  purpose  of 
insuring  that  certain  processes  on  the  CCN  get  all  air  track  information 
or  surface  track  information  etc). 

Convert  ASCII/binary . 

Convert  to/ from  CCN  format. 

Allow  an  option  to  disable  the  default  of  receiving  all  tracks  and 
receive  only  certain  tracks  based  on  seme  filter. 

3.2  CHARACTERISTICS  OF  INTEREST 

Figure  4  shows  the  DTS  computer  and  its  attached  NIU. 

i 
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PDP  11/03 
NIU 


UYK-20 
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2400  BAUD 

TO  NET 

NTDS  RS-232 

SLOW 

ASCII 

CHARACTERS 

BINARY  DATA 

50k  BAUD 

Figure  4.  DTS  processor  and  NIU. 


Data  from  the  DTS  computer  come  in  binary  form  over  a  30-bit-wide  NTDS  slow 
line  to  the  NTDS  computer.  In  the  CCN,  an  RS-232  conversion  box  will  sit 
between  the  DTS  and  the  NIU  since  the  LSI-11/03  cannot  be  interfaced  with  NTDS 
slow.  Therefore,  to  the  CCN  the  line  to  the  DTS  will  look  like  an  RS-232 
synchronous  data  line.  The  LSI-1 1/03  here  is  as  described  in  the  introduction 
except  for  the  addition  of  the  synchronous  line  interface.  The  data  from/ to 
the  DTS  are  binary,  with  a  start/stop  data  word  and  a  track  number  for 
historical  purposes.  The  NTDS  control  lines  will  appear  to  the  LSI-11/03  as 
RS-232  control  lines  so  that  the  existing  protocol  (as  described  in  NELC  TM- 
119,  Interface  Design  Specification)  can  be  employed  in  the  LSI-11/03. 

3.3  INITIAL  CCN  CAPABILITY 

3.3.1  Functions  which  will  be  implemented 

Deliver  track  data  from  the  DTS  computer  to  interested  users. 

Prevent  transmission  over  CCN  of  track  reports  containing  no  change  in 
data  fields. 

Signal  the  user  when  tracks  arrive  from  the  DTS  computer. 

Employ  a  multiaddressing  scheme  to  deliver  the  same  tracks  to  several 
users . 

Convert  track  format  from  binary  to  ASCII. 

Convert  to  CCN  format. 
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3.3.2  Functions  which  will  not  be  implemented 

Deliver  track  data  from  users  to  the  DTS  computer. 

Require  users  to  login. 

Inform  users  of  success/failure  of  tracks  sent  to  the  DTS  computer. 

Store  track  data  for  later  retrieval. 

Deliver  tracks  based  on  content. 

Allow  the  NSM  to  have  tracks  sent  to  a  third  party. 

Convert  ASCII  to  binary. 

Convert  from  CCN  format. 

Option  to  pass  all  tracks  or  certain  ones  based  on  some  filter. 

4  CCIS  PROGRAMS 

4.1  FUNCTIONAL  REQUIREMENTS 

Serve  as  the  IP  by  delivering  NAVMACS  RAINFORM  messages  and  DTS  tracks  to 
the  DP. 

Format  the  RAINFORM  messages  and  DTS  tracks  appropriately  for  the  DP. 
Allow  users  to  query  the  QP  and  return  responses  to  them. 

Allow  users  to  send  responses  to  the  IT-624  printer. 

Establish  a  priority  scheme  for  query  users. 

Require  users  to  login. 

Store  queries/responses  if  printer  is  busy. 

Queue  queries  if  QP  is  busy. 

Queue  messages  in  IP  for  DP. 

Send  queries/responses  to  both  the  printer  and  the  user. 

4.2  CHARACTERISTICS  OF  INTEREST 

Figure  5  shows  the  CCIS  processor  and  its  attached  NIU. 
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Figure  5.  CCIS  and  attached  NIU. 


The  QP  and  DP  are  microprocessors  and  the  DP  has  mass  storage  for  its  data 
base.  Lines  1  and  2  are  RS-232  asynchronous  serial  lines  with  data  traversing 
in  both  directions  on  line  1  and  in  one  direction  only  on  line  2.  The  DP 
accepts  data  over  line  2  every  4  seconds  (adjustable).  There  is  no 
acknowled^nent  from  the  DP  over  this  line.  Data  can  arrive  asynchronously 
over  line  1  because  the  QP  provides  a  buffer  for  a  one- line  query  (80 
characters).  Responses  are  sent  back  over  line  1  in  the  same  manner  and  are 
of  variable  length.  An  EOM  is  contained  in  the  data  for  message  delimiting. 

4.3  INITIAL  CCN  CAPABILITY 


4.3.1  Functions  which  will  be  implemented 

Serve  as  IP  by  delivering  RAINFORM  and  DTS  messages  to  DP. 

Format  RAINFORM  and  DTS  messages  appropriately  for  DP. 

Allow  users  to  query  QP  and  return  responses  to  them. 

Allow  users  to  send  responses  to  printer. 

Allow  users  to  send  queries/responses  to  printer  and  to  receive  them. 

4.3.2  Functions  which  will  not  b«  implemented 


i 


Establish  a  priority  scheme  for  query  users. 
Require  users  to  login . 
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Store  queries/ responses  if  printer  is  busy. 

Queue  queries  if  the  QP  is  busy. 

Queue  messages  in  IP  for  DP. 

5  TSA  PROGRAMS 

.  1  FUNCTIONAL  REQUIREMENTS 

Deliver  NAVMACS  messages  to  the  KL-20/40  for  TSA. 

Allow  a  parameter  indicating  what  kind  of  NAVMACS  messages  TSA  is 
interested  in . 

Require  TSA  to  authenticate  itself  as  a  NAVMACS  user,  NAVMACS  printer 
user ,  DTS  user ,  and  QP  user . 

Signal  TSA  when  NAVMACS  messages  arrive. 

Allow  TSA  to  file  the  NAVMACS  messaqes  for  later  retrieval. 

Allow  TSA  to  stop  the  process  at  any  time. 

Inform  TSA  of  net  errors  which  result  in  the  loss  of  NAVMACS  messages. 
Inform  TSA  when  the  NAVMACS  processor  is  being  held  off. 

Allow  TSA  to  send  text  to  the  NAVMACS  IT-624  line  printer. 

Allow  TSA  to  file  text  for  later  printing  if  the  line  printer  is  busy. 

Keep  TSA's  text  separate  from  other  users'  text. 

Prevent  TSA  from  tying  up  the  line  printer. 

Inform  TSA  of  success/ failure  of  printed  text. 

Deliver  DTS  track  data  to  TSA. 

Send  track  data  from  TSA  to  DTS. 

Signal  TSA  when  track  data  arrive. 

Allow  TSA  to  store  tracks  for  later  retrieval. 

Inform  TSA  of  success/failure  of  sent  tracks. 

Allow  TSA  to  query  the  QP. 

Allow  TSA  to  direct  the  query/response  from  the  QP  to  the  line  printer. 
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Allow  TSA  to  both  receive  the  responses  from  the  QP  and  print  them  on  the 
TT-624 . 

Filter  on  subject  or  header  in  NAVMACS  messages. 

Store  the  queries/ responses  sent  to  the  QP  for  later  retrievel  if  the 
printer  is  busy. 

Send  tracks  from  TSA  to  the  DP. 

5.2  CHARACTERISTICS  OF  INTEREST 

TSA  is  a  process  which  runs  on  the  KL-20/40  operating  under  the  TOPS20 
operating  system.  The  KL-20/40  is  interfaced  to  the  PLI  and  uses  the  network 
protocols  TCP4  and  Telnet.  The  KL-20/40  has  256k  words  of  memory  and  370M 
bytes  of  mass  storage.  The  KL-20/40  also  has  an  attached  line  printer  and  16 
asynchronous  communication  lines  for  interactive  terminal  users. 

5.3  INITIAL  CCN  CAPABILITY 

5.3.1  Functions  which  will  be  implemented 

Deliver  NAVMACS  messages  to  the  KL-20/40  for  TSA. 

Allow  a  parameter  indicating  what  kind  of  NAVMACS  messages  TSA  is 
interested  in  but  restricted  to:  all  messages,  or  RAINFORM  formatted 
messages.  (TSA  will  have  the  ability  itself  to  sort  NAVMACS  messages.) 

Signal  TSA  when  NAVMACS  messages  arrive. 

Allow  TSA  to  file  the  NAVMACS  messages  for  later  retrieval. 

Allow  TSA  to  stop  the  process  at  any  time. 

Allow  TSA  to  send  text  to  the  NAVMACS  printer. 

Keep  TSA' s  text  separate  from  other  users'  text. 

Prevent  TSA  from  tying  up  the  printer. 

Deliver  DTS  track  data  to  TSA. 

Signal  TSA  when  track  data  arrive. 

Allow  TSA  to  store  track  data  for  later  retrieval. 

Allow  TSA  to  query  the  QP. 

Allow  TSA  to  direct  the  query/ response  from  the  QP  to  the  NAVMACS 
printer . 

Allow  TSA  to  both  receive  the  response  from  the  QP  and  have  it  printed  on 
the  TT-624. 
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5.3.2  Functions  which  will  not  be  implemented 

Require  TSA  to  authenticate  itself  as  a  user  of  any  of  the  C2  subsystems. 
Inform  TSA  of  net  errors  which  result  in  the  loss  of  NAVMACS  messages. 
Inform  TSA  when  the  NAVMACS  processor  is  being  held  off. 

Allow  TSA  to  file  text  for  later  printing  on  the  NAVMACS  TT-624. 

Filter  NAVMACS  messages  based  on  subject  or  header. 

Send  tracks  from  TSA  to  DP. 

Inform  TSA  of  success/failure  of  printed  text. 

Send  tracks  from  TSA  to  DTS. 

Inform  TSA  of  success/failure  of  sent  tracks. 

Store  the  queries/ responses  sent  to  the  QP  for  later  retrieval  if  the 
printer  is  busy. 

6  TERMINAL  USERS 

6.1  FUNCTIONAL  REQUIREMENTS 

Deliver  NAVMACS  messages  to  terminal  users. 

Accept  a  parameter  defining  the  type  of  NAVMACS  messages  the  user  is 
interested  in . 

Require  the  user  to  login. 

Signal  the  user  when  NAVMACS  messages  arrive. 

Allow  the  user  to  file  the  NAVMACS  messages  for  later  retrieval. 

Allow  the  user  to  stop  the  process  at  any  time. 

Inform  the  user  of  net  errors  which  result  in  the  loss  of  NAVMACS 
messages . 

Print  only  the  headers  of  NAVMACS  messages. 

Inform  the  user  when  the  NAVMACS  processor  is  being  held  off. 

Allow  the  user  to  query  the  QP. 

Allow  the  user  to  direct  queries /responses  from  the  QP  to  the  NAVMACS 
line  printer. 
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Store  queries/ responses  for  later  printing  if  the  TT-624  is  busy. 

Allow  the  user  to  run  TSA. 

Allow  a  user  to  have  NAVMACS  messages  sent  to  a  third  party. 

Allow  users  to  both  receive  NAVMACS  messages  and  send  them  to  the 
printer . 

6.2  CHARACTERISTICS  OP  INTEREST 

Terminal  users  will  have  Telnet  available  so  access  will  exist  to  all  CCN 
resources  from  a  terminal  on  the  CCN.  A  user  can  telnet  to  the  KL-20/40  where 
he  will  De  required  to  loqin .  The  user  can  then  run  TSA  or  any  other  process 
available  on  the  KL-20/40. 

S  3  INITIAL  CCN  CAPABILITY 


6  . ‘  Functions  which  will  be  implemented 

Deliver  NAVMACS  messages. 

Accept  a  parameter  defining  the  type  of  NAVMACS  message  the  user  is 
interested  in  but  limited  to:  all  messages,  or  RAINFORM  formatted 
messages. 

Signal  the  user  when  NAVMACS  messages  arrive. 


Allow  the  user 

Allow  the  user 

Allow  the  user 
printer . 

Allow  the  user 


to  stop  the  process  at  any  time, 
to  query  the  QP. 

to  direct  quer ies/responses  from  the  QP  to  the  NAVMACS 

to  run  TSA . 


6.3.2  Functions  which  will  not  be  implemented 
Require  the  user  to  login. 

Allow  the  user  to  file  NAVMACS  messages  for  later  retrieval. 

Inform  the  user  of  net  errors  which  result  in  the  loss  of  NAVMACS 
messages . 

Print  only  the  headers  of  NAVMACS  messages. 

Inform  the  user  when  the  NAVMACS  processor  is  being  held  off. 

Store  queries/responses  from  QP  for  later  retrieval  if  the  line  printer 
is  busy. 
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Allow  a  user  to  send  a  NAVMACS  message  to  a  third  party 


Allow  the  user  to  both  receive  NAVMACS  messages  and  send  them  to  the 
printer. 


7  NSM 


7.1  FUNCTIONAL  REQUIREMENTS 

Have  NAVMACS  and  DTS  data  sent  to  third  parties. 

Have  NAVMACS  and  DTS  data  filtered  on  content. 

7.2  CHARACTERISTICS  OF  INTEREST 

The  Network  Services  Manager  (NSM)  is  as  of  yet  unspecified.  It  is 
expected  to  perform  many  systemwide  functions  in  the  future  and,  in  general, 
to  monitor  the  network.  It  may  provide  services  such  as  code  conversion  and 
name-server  functions. 

7.3  INITIAL  CCN  CAPABILITY 

The  NSM  will  not  be  available  for  the  initial  CCN. 


GLOSSARY  OF  COMMAND  CENTER  NETWORK  ACRONYMS  AND  ABBREVIATIONS 


ARPANET 

ASCII 

Baudot 


Bit 

Byte 

C2 

CCIS 

CCN 

cpu 

DEC 

DP 

DTS 

EOM 

IMP 

IP 

kbaud 

LSI-11 

LSI-11/03 

MOS 

NAVMACS 

NIU 

NSM 


Advanced  Research  Projects  Agency  Network 

American  Standard  Code  for  Information  Interchange  - 
a  seven-bit  code  used  to  represent  128  symbols 

Seven- level  International  Telegraph  Code  2  using  one 
start  bit,  one  stop  bit,  and  five  bits  representing 
one  of  62  symbols 

Binary  digit 

Eight-bit  word 

Command  control 

Command  Center  Information  Subsystem 
Command  Center  Network 
Central  processing  unit 
Digital  Equipment  Corporation 

Data  Processor  (one  of  three  processors  used  in  the 
CCIS) 

Data  Terminal  Set 

End  of  message 

Interface  Message  Processor 

Interface  Processor  ( one  of  three  processors  used  in 
the  CCIS) 

One  thousand  bits  per  second 

Digital  Equipment  Corporation  processor  model 
Digital  Equipment  Corporation  processor  model 
Micro  Operating  System 

Naval  Modular  Automated  Communications  System 
Network  Interface  Unit 
Network  Service  Manager 
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NTDS 

NTDS  slow 
PDP-11/03 

PLI 

CP 

RAM 

RS-232 

SOM 

SRI 

TCP 

TCP4 

Telnet 

TENEX 

TSA 

TT-624 


Navy  Tactical  Data  System 

Interface  requirements  specified  in  MIL-STD-1397 

Digital  Equipment  Corporation  computer  model  built  on 
an  LSI-11/03 

Private  Line  Interface 

Query  Processor  ( one  of  three  processors  used  in  the 
CCIS) 

Random  access  memory 

EIA  standard  electrical  interface  defining  control 
lines,  voltage  levels,  and  signals  for  exchange  of 
binary  data 

Start  of  message 

Stanford  Research  Institute 

Transport  Control  Protocol 

Transmission  Control  Protocol  version  4 

ARPANET  protocol  which  allows  a  user  at  a  remote  site 
to  login  to  a  time- sharing  system  as  if  he  were  at  a 
directly  connected  terminal 

Operating  system  for  PDP-10  computers  manufactured  by 
Digital  Equipment  Corporation 

Tactical  Situation  Assessment 

Data  General  Corporation  line  printer 
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